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A MECHANISM FOR SYNCHRONOUS INTERPROCESS 
COMMUNICATION OVER TRANSPARENT EXTERNAL MONITORS 

Background Of The Invention 

Field of Invention 

The present invention relates generally to the field of 
interprocess communication. More particularly, this 
invention relates to an interprocess communication 
mechanism that enables the synchrony semantics of each 
communication to be controlled by external entities 
called monitors, such that: (1) communication may be 
redirected to such external entities transparently to the 
sender and receiver of the communication and (2) the 
monitors can determine the semantics of a completed 
communication as they desire. 

Background of the Invention 

Interprocess communication (IPC) monitoring enables the 
examination of any IPC between a source and a 
destination. IPC monitoring is useful for a variety of 
purposes, including debugging, logging, and security. 
For example, a monitor may collect communication state 
for the purpose of debugging a program consisting of 
several independent tasks. Also, a monitor can be used 
to filter communication data or control the communication 
rate for security purposes. 

Transparent monitoring means that the source and 
destination are not aware that they are being monitored. 
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This has two advantages: (1) the system can control the 
insertion and removal of monitors without interacting 
with either the source or destination, and (2) the source 
and destination protocols do not need to take into 
account the possibility that they may be monitored. 
Traditional systems make no attempt to support 
transparent monitoring. Using Mach- style ports (see K. 
Loepere, Mach 3 Kernel Principles, Open Software 
Foundation and Carnegie Mellon University, 1992) , the 
source and destination hold rights that must be revoked 
in order to insert a monitor, so at least one must be 
notified before such a change can occur safely. The 
Pebble microkernel enables transparent redirection of 
source IPCs using its portals to implement customized 
IPC, but the redirection is not transparent to the 
destination because it sees that the message is from the 
redirected task, not the original 

(see E. Gabber et al, Building Efficient Operating 
Systems from User- level Components in Pebble, in 
Proceedings of the 1999 USENIX Annual Technical 
conference, 1999) . 

Other IPC mechanisms, such as Clans & Chiefs (see J. 
Liedtke, Clans & Chiefs, in Architektur von 
Rechensystemen, 1992, in English) and IPC Redirection 
(see, "Flexible Access Control Using IPC Redirection, " 
HotOS 1999) , enable monitors to intercept and forward 
IPCs while claiming to be the original source of the IPC. 
Thus, the destination receives the IPC from the source, 
not the monitor, so it need not know that an IPC is being 
monitored. Unfortunately, such mechanisms are not truly 
transparent because the kernel 1 s IPC semantics are not 
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preserved when a monitor intercepts an IPC. Modern 
microkernels implement a synchronous IPC semantics, which 
means that the source is blocked until the destination is 
ready to receive the IPC or an error occurs (e.g., the 
destination task is killed or a timeout expires) . When 
destination commences receipt, the IPC is sent to the 
destination and the source unblocks. Unfortunately, if a 
monitor is inserted on an IPC path, the source is 
unblocked when the IPC is received by the monitor, not 
the destination. This may result in some anomalous 
behaviors, such as: (1) the source assuming that IPCs 
have been delivered to the destination before they really 
have; (2) the source terminating IPCs due to timeout 
expiration even though the destination is ready, but 
because the monitor was not ready; and (3) the source 
assuming that the IPC was delivered reliably to the 
destination when an error may have occurred. 

What is needed is that the system (i.e., the kernel and 
the monitors) control the synchrony of each 
communication, so that the communication appears to the 
sender and destination to be implemented according to the 
same semantics regardless of whether a monitor is present 
or not. Further, the system may choose arbitrary actions 
upon a communication, so the interprocess communication 
mechanism must permit the system to provide any desired 
semantics. Lastly, the interprocess communication 
mechanism must result in a system that is robust in the 
presence of errors. 
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Summary of the Invention 

An object of this invention is to improve interprocess 
communications . 

Another object of the present invention is to provide a 
method and system for controlling the synchrony of 
interprocess communications so that the communications 
appear to the senders and destinations to be implemented 
according to the same semantics regardless of whether the 
communications are monitored or not. 

A further object of this invention is to use monitors, 
for monitoring interprocess communications, as extensions 
of a system kernel, to that, when a particular 
communication is monitored, the source and destination of 
the communication are treated as if the kernel is still 
processing the communication. 

These and other objects are attained with a method and 
system for performing interprocess cornniuni cat ions (IPCs) > 
The method comprises the steps of receiving IPC requests, 
where each of the IPC requests identifies a source and a 
destination; building IPCs in response to the request; 
transmitting the IPCs from the sources to the 
destinations; and intercepting and examining selected 
ones of the IPCs. The method comprises the further step 
of controlling the synchrony of the IPCs so that each IPC 
appears to its source and destination to be implemented 
according to the same semantics regardless of whether the 
IPC is intercepted and examined. 
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With the preferred embodiment of this invention, the 
system monitors are considered as an extension of the 
system kernel (although they may be linked into the 
kernel and run in kernel mode as well) , so the source and 
destination are treated as if the kernel is still 
processing the IPC. Thus, the desired semantics of 
communication can be implemented in the monitors. 
However, there are a number of possible monitoring 
semantics that may be reasonable, so in order to maintain 
utility of the approach, the IPC mechanism enables the 
monitors to coordinate using a small set of actions. 

These actions are as follows. First, the interception of 
an IPC by a monitor permits the monitor to manage: (1) 
the identity of the source that ultimately must be 
unblocked; (2) when the sender is unblocked; and (3) 
whether the monitor is notified when the communication 
reaches the destination. In addition, error handling 
semantics can be expressed by the monitors such that all 
communication state in the monitors is maintained 
consistently. 

Further benefits and advantages of the invention will 
become apparent from a consideration of the following 
detailed description, given with reference to the 
accompanying drawings, which specify and show preferred 
embodiments of the invention. 

Brief Description of the Drawings 

Figure 1 displays the general mechanism for delivering 
IPCs synchronously regardless of whether one or more 
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monitors are inserted on the IPC path between the source 
and destination. 

Figure 2 displays how the delivery mechanism for IPCs is 
chosen. 

Figure 3 displays how the kernel implements a source to 
monitor IPC delivery. 

Figure 4 displays how the kernel implements a monitor to 
monitor IPC delivery. 

Figure 5 displays how the kernel implements a monitor to 
destination IPC delivery. 

Figure 6 displays the process by which a monitor handles 
IPCs that are redirected to it while managing the 
synchronicity information. 

Figure 7 displays how the monitor prepares an IPC that it 
is forwarding. 

Figure 8 displays how an IPC error message is processed. 

Figure 9 displays how an IPC unblock message is 
processed. 

Figure 10 displays how the synchrony is implemented when 
the IPC is delivered to the destination. 

Figure 11 displays how an IPC error message is built. 



YOR920000575US1 



-6- 



Figure 12 displays how an IPC error message is delivered. 

Figure 13 displays how an IPC unblock message is built. 

Figure 14 displays how an IPC unblock message is 
delivered. 

Figure 15 displays how an IPC notify message is built. 

Figure 16 displays how an IPC notify message is 
delivered. 

Figure 17 displays how the destination to which a source 
is blocked is changed should a monitor redirect the 
message to an alternative final destination. 

Detailed Description of the Preferred Embodiment 

For the preferred embodiment, the L4 microkernel's IPC 
mechanism as the base IPC mechanism. The L4 IPC 
mechanism is described in the L4 Reference Manual. L4 
enables the creation of tasks that can be inserted on 
arbitrary IPC paths. A mechanism called IPC redirection 
is used in the preferred embodiment to determine whether 
an IPC is sent to a monitor or to a destination 
("Flexible Access Control Using IPC Redirection," HotOS 
1999) . One suitable redirection mechanism is disclosed 
in copending patent application no. 09/276,869, filed 
March 26, 1999, entitled "Flexible Interprocess 
Communication via Redirection," the disclosure of which 
is herein incorporated by reference. 
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Figure 1 shows the basic synchronous IPC mechanism that 
enables transparent use of an arbitrary number of 
monitors. First, the source requests an IPC send (100) . 
The sender (in this case, the source) is then blocked 
(110) . The kernel processes the IPC delivery (200) which 
results in the IPC being sent either to the destination 
or a monitor (120) . The kernel uses the IPC redirection 
mechanism to determine whether the IPC is delivered to 
the destination or a monitor. If the IPC is delivered to 
the final destination, then the kernel completes the 
synchronous IPC processing to ensure that the source can 
be unblocked (1000) . If the IPC is delivered to a 
monitor, then the monitor performs its processing and 
maintains the synchrony information of the IPC (700) • 
The monitor then decides whether to forward the IPC to 
the destination (or an alternative destination) or not 
(130) . If the IPC is forwarded, the monitor sends the 
IPC using the mechanisms described in (200) . Otherwise, 
the monitor decides whether to return an error (14 0) . 
Error messages are a new type of IPC, so a new mechanism 
is described for handling them (800) . If no error is 
returned, the monitor simply waits for a subsequent 
request (150) . 

Figure 2 describes how the IPC delivery mechanism is 
chosen (200) . This mechanism is executed by the kernel 
in the preferred embodiment. First, the IPC redirection 
mechanism determines the immediate destination of an IPC 
(210) (220) : (1) an invalid destination indicates that 
the IPC is to be blocked (230); (2) the IPC may be sent 
directly to a destination; or (3) the IPC may be 
redirected to a monitor. In addition to the L4 IPC 
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redirection mechanism, monitor tasks must be signified to 
the kernel, so completion processing can proceed (1000) . 
In either case, the IPC may be deceited (i.e., sent from 
a task claiming to be another (24 0) , and the delivery 
mechanism choice depends on whether a monitor or the 
source directly sent the IPC (250) . Different mechanisms 
are applied for: (1) source to destination delivery (260) 
(this is the standard L4 IPC delivery mechanism, so it is 
not covered); (2) source to monitor delivery (300); 
monitor to monitor delivery (400); or monitor to 
destination 
delivery (500) . 

Figure 3 describes how the kernel processes an IPC 
delivery from a source to a monitor (300) . The kernel 
simply delivers the IPC from the source to the monitor 
(310) and unblocks the monitor (320) . This delivery 
(310) is performed using the traditional deceiting IPC as 
described in the L4 Users 1 Manual, After the IPC is 
delivered, only the monitor is unblocked (320) . The 
source remains blocked. 

Figure 4 describes how the kernel processes an IPC 
delivery from a monitor to another monitor (400) . First, 
the kernel sets the traditional deceiting IPC data for 
the IPC as described in the L4 Users 1 Manual (410) . 
Then, the kernel determines the type of the IPC (42 0) and 
sets the IPC type value appropriately (43 0) . The various 
IPC type values are listed below: 
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IPC type values 



direct IPC: 0 

error: 1 

5 notification: 2 

unblocking: 3 

deceit: 4 

deceit w/ blocked source: 5 

deceit w/ controlling monitor: 6 

10 Both 5 and 6: 7 



The kernel then pushes any synchrony values onto the 
stack of the IPC receiver (440). If the IPC type is 5, 
□ then only the blocked source is pushed. If the IPC type 

tf|5 is either 6 or 7, then both the blocked source and 

m controlling monitor values are pushed. If the IPC type 

H : is 0-4 no parameters are pushed. The kernel then 

% delivers the IPC using the traditional L4 mechanism 

]J& (450) . Both the sender and receiver of the IPC are 

120 unblocked (460) (470) although according to L4 IPC 

;p semantics, the receiver is given the remainder of the 

H ! sender* s timeslice, so it become the next runnable task 

S (480) . 

25 Figure 5 describes how the kernel sends an IPC to the 

destination (500) . Basically, the mechanism is the same 
except that there is no need for the synchrony 
information to be passed to the destination. Therefore, 
IPC types 5-7 are equivalent to 4 in this case. First, 

30 the IPC is prepared for a deceited send as before (410) . 

Then, the IPC type given that the IPC is to be delivered 
to the destination is determined (510) . Then, the IPC 



YOR920000575US1 



-10- 



type is set (43 0) . Next, the IPC is delivered by the 
kernel as is traditional in L4 (450) . Then, the sender 
and receiver are unblocked (460) (470) . Lastly, the 
destination is made runnable (480) . 

Figure 6 describes how the monitor processes the IPCs 
that are redirected to it (700) . IPCs that are intended 
for the monitor are processed as traditional L4 IPCs. 
First, the monitor receives the IPC message and error 
codes (710) . Using this information, the monitor can do 
arbitrary, monitor - specif ic processing (720) . If the 
monitor detects an error (720) (either through the error 
codes or its monitor- specif ic processing), the monitor 
then processes the IPC error (800) . If there is no 
error, then the monitor determines whether to unblock the 
source (740) . If the source is to be unblocked (750) , 
the monitor must process a source unblock (9 00) . 
Regardless, the monitor creates a deceiting IPC message 
typical to L4 except that the monitor can now also 
specify the blocked source and/or the controlling monitor 
(760) . Lastly, the monitor determines whether to update 
the IPC block state of the original source (77 0) . 

Figure 7 describes how the monitors prepare IPCs that 
they are going to forward. First, the monitor sets the 
blocked source (762) and controlling monitor (764) values 
for the IPC as necessary. The blocked source need only 
be set (762) if the identity of the original source of 
the IPC is different than the true source specified in 
the deceited IPC. The monitor may set the value of the 
controlling monitor to (764): (1) null, if none is 
specified; (2) itself if it wants to receive notification 
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when the IPC has been completed (i.e., been delivered to 
the destination); or (3) the current controlling monitor 
value it received in the incoming IPC. Subsequently, the 
monitor completes and delivers a typical L4 deceited IPC 
(766) and then waits for further redirected IPCs (150) . 

Figure 8 describes how an IPC error message is processed 
(800) . First, the monitor builds an IPC error message 
(810) . Second, the monitor asks the kernel to deliver 
the IPC error message using the basic L4 IPC mechanism 
(820) . The IPC error message is itself an IPC, so it can 
be delivered using a slight generalization of the basic 
IPC mechanism. Then, the monitor waits for the next IPC 
(150) . 

Figure 9 describes how an IPC unblock message is 
processed (900) . First, the monitor builds an IPC 
unblock message (910) . Next, the monitor asks the kernel 
to deliver the IPC unblock message (920) . Like the IPC 
error message case, the IPC unblock message is also an 
IPC. Lastly, the monitor waits for the next IPC (15 0) . 

Figure 10 describes the additional IPC effort when the 
IPC is delivered to the destination from the monitor 
(10 00) . At this time, the kernel must determine how to 
proceed with unblocking the source. If a controlling 
monitor is set (1010) (1020) , then a notify message is 
constructed which is used to inform the controlling 
monitor that IPC from the source has been completed 
(1030) . This message is delivered to the controlling 
monitor (1040) . If no controlling monitor is set, the 
kernel then determines whether a blocked source is set 
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(1050) (1060) . If so, the blocked source task is 
unblocked (1070) . Otherwise, the value of the true 
source is unblocked (107 0) . 

Figure 11 describes the mechanism for building error 
messages (810) . The key component is the setting of the 
IPC error type (812) . Following this, the error code of 
the IPC is set (814) . Any IPC message for the source is 
added (816) . Lastly, the blocked source of the IPC is 
set, so the IPC error is delivered to the proper task 
(818) . 

Figure 12 describes how IPC error messages are delivered 
by the kernel (820) . The kernel first determines if the 
monitor is on the IPC path source and destination (821) . 
If so (822), the kernel determines if the source is 
blocked on the destination (823) . If the source is 
blocked on the destination (824) , then the kernel sets 
the IPC error state for the source (825) and unblocks the 
source (826) . If the monitor is not on the proper IPC 
path (822) or the source is not blocked on the 
destination (824) , the IPC error message is terminated 
and an error is returned to the monitor (410) . 

Figure 13 describes the mechanism for building unblock 
messages (910) . The key step is the setting of the IPC 
unblock type (911) . Following this, the error code of 
the IPC is set (912) . Any IPC message for the source is 
added (816) . Lastly, the blocked source of the IPC is 
set, so the IPC unblock is delivered to the proper task 
(818) . 
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Figure 14 describes how IPC unblock messages are 
delivered by the kernel (920) . The kernel first sets the 
blocked source identity to that of the source in the IPC 
(921) . Next, the kernel determines if the monitor is on 
the IPC path between the blocked source and the current 
destination (821). If so (822), the kernel determines if 
the source is blocked on the destination (823) . If the 
source is blocked on the destination (824), then the 
kernel sets the IPC error state for the source to that 
specified in the unblock IPC (825) and unblocks the 
blocked source (107 0) . If the monitor is not on the 
proper IPC path (822) or the sender is not blocked on the 
destination (824), the IPC error message is terminated 
and an error is returned to the monitor (410) . 

Figure 15 describes how a IPC notify message is built 
that informs a controlling monitor of a completed IPC. 
First, the kernel obtains the blocked source of the 
active IPC (1050) . If there is a blocked source (1060) , 
the kernel sets the true source of the notify IPC to the 
blocked source (1032) . If there is no blocked source 
(1060) , then the true source of the notify IPC is set to 
the true source of the active IPC (1033) . The kernel 
sets the destination in the notify IPC to the controlling 
monitor in the active IPC (1034). Lastly, the kernel 
sets the IPC type to notify (1035) . 

Figure 16 describes how the kernel delivers a notify IPC. 
The kernel first verifies that the controlling monitor of 
the active IPC is on the IPC path between the notify 
IPC's true source and the active IPC's destination 
(1041) . If it is on the IPC path (822) , then the kernel 
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delivers the notify IPC as a typical IPC (2 00) . 
Otherwise, the monitor receives a notify error from the 
kernel in its error state (1042) . 

Figure 17 describes how the kernel updates the blocked 
source's destination when the monitor specifies a change 
in destination (770) . First, the kernel gets the blocked 
source value (1050) . If there is a blocked source 

(1060) , then the source of the changed destination is 
then set to the blocked source (771) . Otherwise, the 
source of the changed destination is set to the true 
source (772) . Next, the new destination is retrieved 

(823) • If the source is blocked (824) , then the 
destination in which it is blocked is changed to the new 
destination (775) . Otherwise, no action is taken (774) . 

While it is apparent that the invention herein disclosed 
is well calculated to fulfill the objects stated above, 
it will be appreciated that numerous modification and 
embodiments may be devised by those skilled in the art, 
and it is intended that the appended claims cover all 
such modifications and embodiments as fall within the 
true spirit and scope of the present invention. 
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CLAIMS 



1. A method for controlling the synchrony of interprocess 
communication (IPC) which uses: a. the original sender of 
the communication, called the source; b. the ultimate 
receiver of the communication, called the destination; c. 
a kernel process that is capable of delivering 
communications and unblocking the source of the 
communication; and d. one or more processes, called 
monitors, to which the kernel process may choose to 
deliver a communication to, rather than the destination, 
and which have the ability to request control of when a 
source is unblocked, called the controlling monitor of 
the source, wherein the method for controlling the 
synchrony of interprocess communication comprise the 
following steps: 

d. when the communication is sent by the source, the 
source is blocked by the kernel process; 

e. the kernel either delivers the communication to the 
destination or to a monitor; 

f . the monitor may request that the kernel process make 
it the controlling monitor of the source; 

g. the monitor forwards the communication to the 
destination specifying the source of the communication, 
and the monitor is blocked by the kernel process until 
the communication is delivered either to the destination 
or another monitor; 

h. when the communication is delivered to the 
destination, the kernel process either: (1) signals the 
controlling monitor of the specified source, if any, or 
(2) unblocks the specified source; 
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30 i. the controlling monitor of the source can request that 

31 the kernel process unblock the source at any time after 

32 being signalled that the communication was delivered to 

33 the destination. 

1 2. A method as claimed in claim 1, wherein the monitor 

2 may change the identity of the source that is seen by the 

3 destination while maintaining the identity of the 

4 original source for unblocking purposes. 

1 3. A method as claimed in claim 1, wherein the monitor 

2 may change the identity of the destination to which the 

3 communication is to be delivered. 

ill 4. A method as claimed in claim 1, wherein the message 

J^2 embodied in the communication is not delivered to the 

H : 3 monitor. 

4l 5. A method as claimed in claim 1, wherein the timeouts 

IJ1 on the communication are interpreted as being relative to 

^3 the behaviors of the source and destination. 

+:i 6. A method as claimed in claim 5, wherein the kernel 

□2 process does not deliver the communication to the 

3 destination or a monitor until the destination is ready 

4 to receive the communication and the destination timeout 

5 (i.e., the timeout set by the source on the amount of 

6 time it will wait for the destination to become ready to 

7 receive the communication) has not expired. 

1 7. A method as claimed in claim 5, wherein the kernel 

2 process delivers the communication to the monitor as soon 
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3 as the monitor is ready, and the monitor checks for the 

4 destination timeout's expiration. 

1 8. A method as claimed in claim 5, wherein the kernel 

2 process verifies the source timeout (i.e., the timeout 

3 set by the destination on the amount of time it will wait 

4 for the source to initiate the communication) has not 

5 expired before sending the communication to the 

6 destination or a monitor. 

1 9. A method as claimed in claim 1, wherein multiple 

2 monitor processes may claim to be the controlling monitor 

3 of a source. 

2l 10. A method as claimed in claim 1, wherein the kernel 

j|!2 process may authorise a monitor's permission to be the 

H;3 controlling monitor of a particular source. 

¥>\ il. A method as claimed in claim 10, wherein the kernel 

IU2 process may authorize a monitor's permission to be the 

=03 controlling monitor of any source. 

%\ 12. A method as claimed in claim 1, wherein the 

□2 controlling monitor for a particular source may be stored 

3 in the kernel . 

1 13. A method as claimed in claim 9, wherein a sequence of 

2 controlling monitors for a particular source may be 

3 stored in the kernel. 
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1 14. A method as claimed in claim 1, wherein the identity 

2 of the controlling monitor of a particular source is 

3 passed in the IPC to the destination. 

1 15. A method as claimed in claim 14, wherein the sequence 

2 of controlling monitors for a particular source is stored 

3 by the controlling monitor storing its controlling 

4 monitor predecessor for each source. 

1 16. A method as claimed in claim 1, wherein the 

2 controlling monitor for a source is implemented by 

3 changing the original source to the controlling monitor 

4 and the controlling monitor stores the identity of the 
^5 original source. 

$fi\ 17. A method as claimed in claim 16, wherein a sequence 

s a = 2 of controlling monitors for a particular source is 

s p3 implemented as a sequence of original source changes in 

r " ; 4 the monitors where the last is the true original source. 

MS 1 18. A method as claimed in claim 1, wherein the monitors 

S P 2 are implemented as threads in the same process. 

y l 19. A method as claimed in claim 1, wherein the monitors 

2 are implemented as procedures in the same process. 

1 20. A method as claimed in claim 1, wherein the monitor 

2 procedures are in the kernel process. 

1 21. A method of performing interprocess communications 

2 (IPCs), comprising the steps of: 
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3 an IPC process receiving IPC requests, each of 

4 the IPC requests including a source identifier 

5 identifying a source and a destination identifier 

6 identifying a destination; 

7 building IPCs in response to the requests; 

8 transmitting the IPCs from the sources to the 

9 destinations; 

10 intercepting and examining selected ones of the 

11 IPCs; and 

12 controlling the synchrony of the IPCs so that 

13 each IPC appear to the source and to the destination to 

14 be implemented according to the same semantics regardless 

15 of whether the IPC is intercepted and examined. 

ml 22. A method according to Claim 21, wherein: 

\P*2 the step of building and transmitting IPCs 

!~=3 includes the step of using a kernel to build and transmit 

s p4 the IPCs; 

p "5 the step of intercepting and examining selected 

□6 ones of the IPCs includes the step of using monitors to 

intercept and examine the selected ones of the IPCs; and 
! P 8 the controlling step includes the step of using 

0 9 the monitors as extensions of the kernel so that the IPCs 

HlO appear to the sources and to the destinations to be 

11 implemented according to the same semantics regardless of 

12 whether a monitor is used or not used to intercept and 

13 examine the IPCs. 

1 23. A method according to claim 22, wherein, for each 

2 IPC, one or more of the monitors manages the identity of 

3 the source for the IPC. 
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24. A method according to Claim 22, further comprising 
the step of, for each IPC, blocking the source for the 
IPC at selected times, and wherein one or more of the 
monitors manages when the source is unblocked. 

25. A method according to Claim 22, wherein, for each 
IPC, one of the monitors manages whether the monitor is 
notified when the IPC reaches the destination for the 
IPC. 

26. An interprocess communications (IPCs) system, 
comprising: 

a processor having an IPC process for receiving 
IPC requests, each of the IPC requests including a source 
identifier identifying a source for the IPC and a 
destination identifier identifying a destination for the 
IPC; 

means for building IPCs in response to the 

requests ; 

means for transmitting the IPCs from the 
sources to the destinations; 

means for intercepting and examining selected 
ones of the IPCs; and 

a controller for controlling the synchrony of 
the IPCs so that each IPC appear to the source and to the 
destination for the IPC to be implemented according to 
the same semantics regardless of whether the IPC is 
intercepted and examined. 

27. A system according to Claim 26, wherein: 

the means for building and transmitting IPCs 
includes a kernel to build and transmit the IPCs; 
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4 the means for intercepting and examining 

5 selected ones of the IPCs include monitors to intercept 

6 and examine the selected ones of the IPCs; and 

7 the monitors are used as extensions of the 

8 kernel so that the IPCs appear to the sources and to the 

9 destinations to be implemented according to the same 

10 semantics regardless of whether a monitor is used or not 

11 used to intercept and examine the IPCs. 

1 28. A system according to claim 26, wherein, for each 

2 IPC, one or more of the monitors manages the identity of 

3 the source for the IPC. 

y 1 29. A system according to Claim 26, wherein, for each 

ml IPC, the source for the IPC is blocked at selected times, 

P'l 3 and one or more of the monitors manages when the source 

C 4 is unblocked. 

^1 30. A system according to Claim 26, wherein, for each 

□ 2 IPC, one of the monitors manages whether the monitor is 

fl 3 notified when the IPC reaches the destination for the 

J 4 IPC. 

1 31. A program storage device readable by machine, 

2 tangibly embodying a program of instructions executable 

3 by the machine to perform method steps for performing 

4 interprocess communications (IPCs) , said method steps 

5 comprising: 

6 an IPC process receiving IPC requests, each of 

7 the IPC requests including a source identifier 

8 identifying a source and a destination identifier 

9 identifying a destination; 
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10 building IPCs in response to the requests; 

U transmitting the IPCs from the sources to the 

12 destinations; 

13 intercepting and examining selected ones of the 

14 IPCs; and 

15 controlling the synchrony of the IPCs so that 

16 each IPC appear to the source and to the destination to 

17 be implemented according to the same semantics regardless 

18 of whether the IPC is intercepted and examined. 

1 32. A program storage device according to Claim 31, 

2 wherein: 

3 the step of building and transmitting IPCs 

□4 includes the step of using a kernel to build and transmit 

~ 5 the IPCs; 

J15 the step of intercepting and examining selected 

*j ones of the IPCs includes the step of using monitors to 

2 8 intercept and examine the selected ones of the IPCs; and 
^9 the controlling step includes the step of using 

Ljo the monitors as extensions of the kernel so that the IPCs 

fll appear to the sources and to the destinations to be 

tyi implemented according to the same semantics regardless of 

Efl3 whether a monitor is used or not used to intercept and 

3l4 examine the IPCs . 

1 33. A program storage device according to claim 32, 

2 wherein, for each IPC, one or more of the monitors 

3 manages the identity of the source for the IPC. 

1 34. A program storage device according to Claim 32, 

2 further comprising the step of, for each IPC, blocking 

3 the source for the IPC at selected times, and wherein one 
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4 or more of the monitors manages when the source is 

5 unblocked. 

1 35. A program storage device according to Claim 32, 

2 wherein, for each IPC, one of the monitors manages 

3 whether the monitor is notified when the IPC reaches the 

4 destination for the IPC. 
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A MECHANISM FOR SYNCHRONOUS INTERPROCESS 



COMMUNICATION OVER TRANSPARENT EXTERNAL MONITORS 



ABSTRACT 



A method and system for performing interprocess 
communications (IPCs) . The method comprises the steps of 
receiving IPC requests, where each of the IPC requests 
identifies a source and a destination; building IPCs in 
response to the request: transmitting the IPCs from the 
sources to the destinations; and intercepting and 
examining selected ones of the IPCs. The method 
comprises the further step of controlling the synchrony 
of the IPCs so that each IPC appears to its source and 
destination to be implemented according to the same 
semantics regardless of whether the IPC is intercepted 
and examined. With the preferred embodiment of this 
invention, the system monitors are considered as an 
extension of the system kernel (although they may be 
linked into the kernel and run in kernel mode as well) , 
so the source and destination are treated as if the 
kernel is still processing the IPC. Thus, the desired 
semantics of communication can be implemented in the 
monitors . 
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